Titanic is a 1997 Oscar-winning film starring Leonard DiCaprio and Kate Winslet (who will from now on be referred to as K8 Winslet) in a love story aboard the ill-fated Titanic ship. As we know, the Titanic was an “unsinkable ship” - the largest ship in the world at that time - yet it sank mere days into its maiden voyage, costing the lives of 1500 people on board when it hit an iceberg and sunk to the bottom of the North Atlantic on April 15, 1912.
I want to reimagine the ending of the Titanic, both the ship’s ending and the film’s. We’re going to look at the story through the lens of Kubernetes and distributed database technology to see how the story could have ended happily.
The Titanic: A Grand, Expensive, Single-Instance Database
Think of the original Titanic as a single instance database. This can be a single large instance in a cloud, or a large on-prem Oracle setup. It is grand, expensive, and monolithic. When sailing is smooth, things are great! There are fancy dinners and rambunctious parties.
But if your single instance database were to crash into an iceberg, there’s no practical, immediate recovery. If there were an outage, it could take hours or days to recover all that was lost. Whether it’s due to a natural disaster, human error, or an iceberg, outages happen. Shouldn’t your database (and your ship) be prepared to handle worst case scenarios?
Why Did the Titanic Sink? A Quick Diversion Into Poor Architecture
Here are some of the mechanics behind why the Titanic — the “unsinkable ship” — sank. The Titanic had 16 compartments in the hull of the ship, separated by partitions called bulkheads. They were designed this way so if there were a hole in the ship, the bulkheads ensured only one compartment would fill with water. The issue was that the bulkheads did not reach the deck above. Instead, each bulkhead stopped 10 feet above the waterline. Think of this as a wall that almost reaches the ceiling above it. When the Titanic struck the iceberg, 5 of the 16 compartments were breached, which caused the bow to dip. This made the water flow into all the compartments. As soon as one filled up, water continued to rush over the bulkhead, and the ‘unsinkable’ ship sank within 3 hours.
Once the hull of the ship was breached, there was nothing to stop the ship from sinking. What’s worse, there were not enough lifeboats to save everyone on board.
Disaster Recovery for Boats & Databases
Disaster recovery in a single instance “Titanic database” is typically done through asynchronous replication, which slows down considerably when there are more transactions and a limited amount of throughput. Only companies with lots of extra resources are able to pay for a high availability version of their single instance database.
In the case of the Titanic, there were too many people who needed to be saved (transactions), and not enough lifeboats (throughput). The only people who were able to be saved were the upper class, who paid much more money for their high-end experience.
Ok, so what does any of this have to do with Kubernetes?
Let’s Reimagine the Titanic With Kubernetes & a Distributed Database
Now let’s imagine the Titanic could be rebuilt to remove its single point of failure. What would it take to make it a highly available, disaster-recovering ship of our dreams?
Distribute & Replicate: What if we had MORE Titanics? Instead of a single, monolithic ship, let’s distribute and replicate our Titanic to have two identical boats to ride alongside it. This divides the party across three boats instead of one, while also adding capacity in case one of the boats suffered a catastrophic issue. Even in the face of catastrophe, we can just add more replicas! No need to worry about running out of lifeboats. Think of these as your distributed database.
Let’s Add a “Helm Chart”
At the literal helm, let’s introduce a Helm chart. Helm gets our ships running in the water and helps us chart a course for success, but it can’t do much without someone to keep an eye on all the gauges.
The Ship Captain Will Be Played By “The Operator”
Now let’s imagine an upgraded ship captain, played by “the operator” to control all onboard functioning. The operator gives the crew information about directions, outside conditions, and ship status. It allows our crew to upgrade parts of the ship while it’s moving. Imagine changing the engine without losing any time. It even comes with a security staff that lives aboard the ship. The operator makes running Kubernetes with a database significantly easier. With an operator, the Titanic would probably have never struck the iceberg in the first place.
Our Reimagined Titanics
On our reimagined Titanic — or really, Titanics because we will run three boats instead of one — we can now play out the love between Rose K8 Winslet and Jack, and rewrite the ending to be a happy one.
Rose aka K8 Winslet: Constricted, Static, Stateless
Rose aka “K8 Winslet”, our heroine, feels as constricted by her lifestyle as she is by her corset. K8 is a product of her environment–an upper class young woman in the early 20th century who was raised to play a very specific part in society. We could say that K8 was raised to be stateless. Boring, static, akin to an unchanging web page.
Jack Dawson: Lively, Dynamic, & Full of …State?
Jack Dawson represents CockroachDB in the Kubernetes (K8) and CockroachDB love affair. Jack is lively, dynamic, and fearless. When K8 met Jack, her perspective changed. With Jack/CockroachDB, K8 could become stateful. K8 could finally be dynamic, interesting, and grow to her full potential.
On our reimagined distributed Titanics, if one of our ships hit an iceberg, one (Kubernetes) container might fill with water, but it would not affect any of the other containers. This means that the ship will not sink if one container in the hull is breached.
In the event of an outage scenario in which one of our boats were to sink, there would be two other ships to transfer passengers to, as well as enough lifeboats for everyone aboard. Similarly, in a disaster recovery scenario with Kubernetes and CockroachDB, all data ranges on a destroyed node are able to safely transfer to another node. None of the passengers or crew members are lost. Database transactions can continue near, far, wherever you are, and go on and on without fail.
Rose K8 Winslet and Jack (CockroachDB) are a love story for the books, and if only the original Titanic had followed design patterns of distributed systems, nobody would have died in the end. The bulkheads would have been built properly, distributed ships would have ensured recovery in the face of disasters, and there are enough lifeboats for everyone.
And in case anyone is wondering, hypothetically, of course there is enough room for both K8 and CockroachDB on that piece of wood! CockroachDB and Kubernetes were meant to be, and you can run mission critical operations on CockroachDB on Kubernetes. And that is something to “never let go” of!
